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DATA FLOW BETWEEN A COMMUNICAT ION NODE AND A MOBIL E NOD E 

IN A M OBILE NETWORK 

Field of the Invention 

5 

This invention relates to telecommunication systems in 
which data flows between mobile nodes, for example 
personal digital assistants with wireless communication 
capability, and a data network, for example the Internet. 

10 

Background of the Invention 

The Internet is becoming more and more popular, and users 
increasingly wish to access the Internet whilst on the 
15 move. Different types of mobile nodes (i.e. mobile 

communication units) may be employed for this purpose, 
for example a mobile telephone or a personal digital 
assistant (PDA) with wireless communication capability. 

20 Increasingly, mobile users are accessing the Internet via 
different types of fixed or wireless access networks, for 
example a cellular radio communication network, such as a 
Universal Mobile Telecommunication System (UMTS) network, 
a HiperLAN/2 or IEEE 802.11b local area network, a 

25 Bluetooth local communication system,, or fixed accesses 
such as the Ethernet, and so on. The data route between 
the mobile node and the Internet further comprises an 
Internet protocol subnet (IP subnet) , such that the route 
is as follows: mobile node - access network - IP subnet - 

30 Internet (and reverse order for the data route from the 
Internet to the mobile node) . 
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It is currently possible to seamlessly handover accessing 
of the Internet from one access network to another, for 
example by using a protocol known as Mobile-IP. 

5 Traditional mobility support aims to provide continuous 
Internet connectivity to mobile hosts, thereby allowing 
individual mobile users to connect to the Internet whilst 
being mobile and moving their Internet access location. 
In contrast, network mobility support is concerned with 

10 situations where an entire network changes its point of 
attachment to the Internet topology and thus its 
accessibility in the topology. Such a network in 
movement can be called a Mobile Network. 

15 There exist a large number of scenarios where such Mobile 
Networks exist. For example, a Personal Area Network 
(PAN, i.e. a network of several personal devices attached 
to an individual) is known whereby the PAN changes its 
point of attachment to the Internet topology whilst the 

20 user is walking in a shopping mall. In addition, a 

network may be embedded in a bus or aircraft, providing 
on-board Internet access to passengers. A passenger may 
use a single communication device (e.g. a laptop) or be 
itself a Mobile Network (e.g. a PAN) . Notably, this 

25 configuration illustrates a case of a Mobile Network 
visiting a Mobile Network (i.e. nested mobility). 

As such, a Mobile Network can be defined as a set of 
nodes composed of one or more IP- subnets attached to a 
30 Mobile Router (MR) . These IP subnets may also be viewed 
as a mobile unit, with respect to the rest of the 
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Internet, i.e. a MR and all its attached nodes (so called 
Mobile Network Nodes or MNNs) . 

A document [1] authored by Thierry Ernst, Hong-Yon Lach, 
5 IETF Internet -Draft draft-ernst-monet-terminology-00.txt, 
February 2002, describes a list of definitions for the 
Mobile Network terminology that can be applied in this 
application. In particular, the following terms may be 
defined as follows: 

10 

(i) A Local Fixed Node (LFN) : 

A node permanently located within the Mobile Network and 
that does not change its point of attachment. A LFN can 
either be a Local Fixed Host (LFH) or a Local Fixed 
15 Router (LFR) . 

(ii) A Local Mobile Node (LMN) : 

A local mobile node is one that belongs to the Mobile 
Network and changes its point of attachment from a link 
20 within the Mobile Network to another link within or 

outside the Mobile Network. In this regard, it can be 
assumed that the home link of the LMN is a link within 
the Mobile Network. A LMN can either be a Local Mobile 
Host (LMH) or a Local Mobile Router (LMR) . 

25 

(iii) A Visiting Mobile Node (VMN) : 

A VMN is one that does not belong to the Mobile Network, 
and changes its point of attachment from a link outside 
the Mobile Network to a link within the Mobile Network 
30 (i.e. the home link of the VMN is not a link within the 
Mobile Network) . A VMN that attaches to a link within 
the Mobile Network obtains an address on that link. A 
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VMN can either be a Visiting Mobile Host (VMH) or a 
Visiting Mobile Router (VMR) . 

(iv) A Mobile Network Prefix: 

5 A bit string that consists of a number of initial bits of 
an IP address, which identifies a Mobile Network within 
the Internet topology. Nodes belonging to the Mobile 
Network (i.e. at least MR, LFNs and LMNs) share the same 
IPv6 "network identifier" . For a single mobile IP- 
10 subnet, the Mobile Network Prefix is the "network 
identifier" of this subnet. 

(v) An Egress Interface of a MR: 

This is the interface attached to the home link if the 
15 Mobile Network is at home. Alternatively, it is the 
interface attached to a foreign link if the Mobile 
Network is in a foreign network. 

(vi) An Ingress Interface of a MR: 

20 This is the interface attached to a link inside the 
Mobile Network. The concept of egress and ingress 
interfaces can be extended to other types of nodes within 
a mobile network as follows : 

(a) All network interfaces of hosts (fixed or 
25 mobile) in a mobile network are said to be egress 

interfaces. None of them is said to be an ingress 
interface . 

(b) A fixed router in a mobile network (i.e. 
LFR) may have several egress and ingress interfaces. The 

30 type of each interface should be pre -configured on such 
routers. An egress interface is usually an interface on 
the shortest path to a Mobile Router. A fixed router in 
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a mobile network should have at least one egress 
interface . 

(vii) A MR may have multiple Egress and Ingress 
5 interfaces . 

(viii) A mobile network may have multiple MRs . 

Recently, there has been a lot of interest and research 
10 into the Mobile IPv6 specification, as described in the 

document [2] authored by David B. Johnson: IETF Internet- 
Draft draft-ietf-mobileip-ipv6-15.txt, July 2001. A 
major concern with Mobile Ipv6 is that the research has 
proven that the IPv6 standard is currently unable to 
15 adequately address network mobility. In particular, the 
document [3] authored by Thierry Ernst and Hong- Yon Lach: 
IETF Internet -Draft draf t-ernst-mobileip-v6-network- 
02.txt, June 2001, details problems encountered with 
Mobile-IPv6 in supporting Mobile Networks. 

20 

In summary, it has been determined that even if a MR' s 
Home Agent (HA) is able to intercept packets addressed to 
MNNs that are operating behind the MR, the MR's HA is 
clearly unable to encapsulate them to the care-of -address 

25 of the appropriate MR. Note that every data packet has a 
source address and a destination address. A tunnelled 
packet is a packet that encapsulates in it another 
packet. Thus, the encapsulating packet has a pair of 
source and destination addresses. A further encapsulated 

30 packet has additional source and destination addresses. 
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The lack of knowledge of a true location of a particular 
MNN results from the HA not knowing any (never mind a 
preferred) data route to the Mobile Network, once it has 
moved to a * visited' location. Unfortunately, when a MR 
5 registers with its HA the MR only informs the HA to 

record a host-specific route in its routing table. The 
inventors of the present invention have recognised that a 
preferred network route generated using the mobile 
network address (prefix, prefix length and care-of- 
10 address) of the appropriate MR would greatly assist in 
this matter. 

In the field of this invention, the Mobile IPv4 
specification, detailed in [4] C. Perkins, IETF RFC 3220, 
15 U IP Mobility Support for IPv4", Standards Track, January 
2002, describes how Network Mobility can be supported in 
the case of IPv4 mobility. However, it has also been 
determined that IPv4 does not support route optimisation 
for MNNs behind the MR. 

20 

Thus, all the (incoming and outgoing) traffic between a 
MNN and its corresponding nodes (CNs) is passed to the 
MR's Home Agent. This problem is exacerbated in the case 
of nested mobility, which is where a CN wishes to pass 

25 data to a MNN that is behind a number of MR links, or a 
mobile node visiting a mobile network. In the case of 
nested mobility, the packet will thus be encapsulated 
several times as a result of being routed through all of 
the Home Agents of all the nested MRs . This is clearly 

30 inefficient routing. 
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Similarly, in the case of IPv6, the document [5] authored 
by T. J. Kniveton: IETF Internet -Draft draf t-kniveton- 
mobrtr-00.txt, November 2001 describes how to support 
mobile networks with no modifications to Mobile IP (v4 or 
5 v6) . The mechanism proposed to address the support of 
nested mobility is described with respect to FIG. 2. It 
suffers from the same problem of multiple tunnelling by 
the Home Agents of the nested mobile routers as described 
in the previous paragraph. When a MR, for example MR2 

10 260, has attached to a visited network 110 (via another 
Mobile Network MR1 link) , a bi-directional tunnel 210, 
215, 220 is established between MR2 260 and its HA - HA2 
250. When a node, for example LFN2 165, is attached to 
MR2 26 0 and wishes to send an IP packet to a CN, say CN2 

15 255, via the Internet 115, that packet is tunnelled by 
MR2 260 (to HA2 250) and again by MR1 150 (to HA1 240) . 
The multiple- tunnelled data packet is then passed to the 
HA of the latest MR to tunnel the data, namely to HA1 
240. HA1 240 then forwards it to the intended recipient 

20 CN2 255 via the source MR's HA, namely HA2 250. 

This proposed data routing method, and the problems 
associated with it, are best described by way of an 
example. Thus, let us assume that LFN2 165 sends a data 

25 packet to CN2 255. The data packet is first routed 205 
towards MR2 260. The data packet is then tunnelled by 
MR2 260 to be sent to HA2 250. This tunnelling process 
of the data packet from MR2 260 to HA2 250 is itself, by 
necessity, first routed 210 towards its linked MR, namely 

30 MR1 150. MR1 150 further tunnels the data and forwards 
215 the multiple-tunnelled packet to its HA, namely HA1 
240. HA1 240 de-tunnels the data packet, as tunnelled by 
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MR1 150 and forwards 220 the partially de-tunnelled 
packet to its original intended recipient, HA2 250. HA2 
250 further de-tunnels the packet, as tunnelled by MR2 
260, and forwards 225 the wholly de- tunnelled data packet 
5 to CN2 255. 

Clearly, the solution proposed does not provide any 
support for route optimisation, since both inbound and 
outbound packets are routed through the Home Agent of 

10 both MRs 150, 260. In fact, packets from CN2 255 

addressed to LFN2 165 will follow the same path (in 
reverse order) and will then be encapsulated by each Home 
Agent 240, 250 of each of the nested MRs 150, 260. Once 
again, this is clearly inefficient routing, particularly 

15 for a practical situation whereby there may be many more 
than two levels in the nested network. 

The solution presented in a document authored by Thierry 
Ernst and Hong-Yon Lach: IETF Internet -Draft draft-ernst- 

20 mobileip-v6-network-02.txt, June 2001, proposes a means 
for supporting network mobility in the framework of 
Mobile IPv6. This solution introduces the following 
concept: when a Mobile Router roams to a visited network, 
it sends a Prefix Scope Binding Update to its Home Agent 

25 (HA) . Unlike a classical Mobile IPv6 Binding Update 

message, a Prefix Scope Binding Update does not bind a 
home address with a care-of address. 

In contrast, the MR Prefix is bound with the MR care-of 
30 address, for a particular MR. Upon reception of a packet 
whose prefix matches with the MR prefix, the Home Agent 
must then tunnel the packet to the MR care-of -address 
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that has been identified as being able to deliver the 
tunnelled packet to the intended recipient. Likewise , a 
MR may send prefix- scope BUs to the corresponding nodes 
of the nodes it serves. This solution brings a more 
5 efficient support of mobile networks to Mobile IPv6, 
since it may provide a limited improvement to route 
optimisation . 

However, the scope of this draft has explicitly excluded 
10 . the case of nested mobility, which presents a significant 
hurdle to efficient route optimisation. As such, the 
solution proposed in the Thierry Ernst document, IETF 
Internet-Draft draf t-ernst-mobileip-v6 -network- 02 . txt , 
June 2001, fails to provide a useful solution to route 
15 optimisation in many practical situations. Again, the 

problems that emanate from this document, particularly in 
the case of nested mobility, are best highlighted in an 
example situation. 

20 Referring now to FIG. 3, a mechanism for routing data 

packets in an IPv6 network using the proposal of Thierry 
Ernst : IETF Internet -Draf t draf t-ernst-mobileip-v6- 
network-02.txt, June 2001. Notably, the problems 
emanating from using this mechanism in a nested mobility 

25 are highlighted. 

A mobile router MR1 150 is attached to a visited link 
110. A mobile router MR2 260 is attached to MRl's link 
155. A local fixed node LFN2 165 is attached to MR2's 
30 link 230. Again, let us assume that LFN2 165 is 

attempting to communicate with, a corresponding node CN2 
255. 
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Let us further assume that, at the beginning of the 
simple scenario detailed in FIG. 3, MR1 150 and MR2 260 
have already sent BU messages to their respective HAs 
5 240, 250. That is, HA1 240 knows that MRl's 150 prefix 
is reachable at MRl's care-of address. Similarly, HA2 
250 knows that MR2's 260 prefix is reachable at MR2's 
care - of addr e s s . 

10 When a data packet is sent from CN2 255 to LFN2 165, CN2 
255 has no knowledge about LFN2's 165 actual location. 
Thus, the data packet that it sends is therefore routed 
325 towards home link-2 105. HA2 250 intercepts the data 
packet and tunnels it to MR2's care-of address. This can 

15 be understood, as HA2 250 knows that MR2 ' s prefix is 
reachable at MR2's care-of address. 

This tunnelled packet (from HA2 250 to MR2's 260 care-of 
address) is routed 320 toward link-1 245, since MR2's 260 
20 care-of address matches MRl's 150 prefix. HA1 240 

intercepts the data packet and tunnels it to MRl's care- 
of address, namely towards the visited link 110, since 
HA1 240 knows that MRl's prefix is reachable at MRl's 
care-of address. 

25 

MR1 150 then de-tunnels the data packet received from HA1 
240. MR1 150 then forwards the content to the original 
recipient, MR2 260. Meanwhile, MR1 150 sends a Binding 
Update to the sender of the encapsulated packet (that is 
30 HA2 250) to inform it that MRl's prefix is reachable at 
MRl's care-of address. Note that from MR1 1 s point of 
view, HA2 250 is a Correspondent Node and not its Home 
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Agent (i.e. the 'H 1 bit in the BU is not set) . It is up 
to the HA2 250 to accept this Binding Update or not. 

MR2 260 de- tunnels the data packet that it received (i.e. 
5 the portion of the data packet that had been encapsulated 
by HA2 250) and forwards the content (the initial packet 
from CN2 255) to LFN2 165. Meanwhile, MR2 260 sends a 
Binding Update message to the sender of the encapsulated 
packet (that is, CN2 255) to inform it that MR2 ' s prefix 
10 (covering the LFN2 165 address) is reachable at MR2's 

care-of address. This information is stored in the CN's 
binding cache 3 70. 

Once an initial packet has reached its destination, 
15 transmission of a second or subsequent packet from CN2 

255 to LFN2 165 leads to the scenario depicted in FIG. 4. 
After having reviewed its binding cache 370, CN2 255 
recognises that LFN2 165 is reachable at MR2 ' s care-of 
address . 

20 

Thus, it sends the data packet to MR2's care-of -address 
with a routing header for LFN2 165. MR2 ' s care-of - 
address belongs to MRl's link and is therefore routed 
towards Home Link-1 245. In this manner, a minor 
25 improvement to route optimisation is achieved by the 

bypassing of the transmission of the data packet to, and 
from, HA2 250. 

HA1 24 0 then intercepts the data packet and tunnels the 
30 packet to MRl's care-of address, since HA1 240 knows that 
MRl's prefix is reachable at MRl's care-of address. 
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MR1 150 de- tunnels the packet from HA1 240 and forwards 
the content to the mobile router MR2 2 60 of the 
originally intended recipient, LFN2 165. Meanwhile, MR1 
150 sends a Binding Update to the sender of the 
5 encapsulated packet (that is, CN2 255) to inform it that 
MRl's prefix is reachable at MR1 1 s care-of address. 

When receiving the original packet as sent by CN2 255, 
MR2 2 60 replaces its address in the destination field of 
10 the packet with the address contained in the routing 

header (that is, LFN2 165) and forwards the data packet 
to the ultimate recipient . 

The inventors of the present invention have identified a 
15 significant problem with the scenario depicted in FIG. 4. 
All subsequent packets from CN2 255 to LFN2 165 will be 
routed in exactly the same manner as the second data 
packet. That is, there will be no subsequent improvement 
towards route optimisation. This is more clearly shown 
20 in respect of FIG. 5. 

Referring now to FIG. 5, a known binding cache 500 is 
illustrated. The binding cache comprises a list of 
entries, specific to each MR in a nested mobility 

25 scenario. The binding cache entries include, for example 
a MR3 prefix and prefix length 53 0, with a link 532 to a 
determined MR3 care-of -address 534, if one has been 
determined. The MR3 entry 535 is linked 536 to the next 
entry in the binding cache, namely that for MR2 . The MR2 

30 prefix and prefix length 52 0, includes a link 522 to a 
determined MR2 care-of -address 524, if one has been 
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determined. A similar arrangement and link 526 is 
performed to MR1, and so on. 

In addition, the binding cache entries include a flag 
5 entry (not shown) . A *P' flag is the "Prefix Scope 
Registration" flag. When it is set, a "Home Address" 
field is filled with the Mobile Network prefix (the 
prefix that is advertised by the Mobile Router) and the 
"Prefix Length" corresponds to the length of the Mobile 
10 Network prefix. 

It is specified in the document by Thierry Ernst: IETF 
Internet -Draft draf t-ernst-mobileip-v6-network-02 . txt , 
June 2001, that the Binding Cache is searched for an 

15 entry corresponding to the destination address of the 
packet in one pass. As a result of the search, either 
nothing has been found (no entry) , or the full address 
has been found (12 8 -bit match for an IPv6 address, P flag 
unset) , or the first bits of the destination address 

20 match with a registered prefix for the registered prefix 
length. In the latter case, the destination is located 
in a mobile network. 

Therefore, with reference to FIG. 4, when CN2 255 has to 
25 send a packet to LFN2 165, CN2 255 still reviews its 
binding cache and finds the entry *MR2 260 prefix 
reachable at MR2 260 Co®' 520, 524. CN2 255 does not 
even consider the entry *MR1 150 prefix reachable at MR1 
Co®' 510, 514, as this would appear to have no bearing on 
30 the LFN2 address. The inventors have recognised that 

this deficiency results from the LFN2 165 address being 
unrelated to the MR1 prefix. The fact that MR2 26 0 Co® 
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belongs to MR1 prefix is neither seen, nor even used by 
CN2 255. 

Consequently, the only optimisation that the Thierry 
5 Ernst proposal can support is related to the HA (HA2 250) 
of the MR (MR2 260) serving the communicating MNN (LFN2 
165 in the above example) . This solution describes 
indeed a means for having packets be sent directly from 
CN2 255 to HA1 240, instead of CN2 255 to HA2 250 and 
10 thereafter to HA1 240. However, if there were n 

successive levels of nested mobility, this solution 
provides minimal route optimisation, no more than having 
a CN2 255 HA n -i -» HAn- 2 ~> ... -> HA1 path instead of CN2 
255 -> HAn -» HAn-x -> HA n . 2 •» ~> HA1 path. This proposal 
15 is therefore still clearly inefficient, particularly in 
the case of nested networks. 

A need therefore arises for a mechanism, apparatus and 
associated methods to support route optimisation in 
20 Network mobility, especially in the case of IPv6. In 
particular, a need has arisen to support route 
optimisation in the case of nested mobility, wherein the 
aforementioned problems are substantially alleviated. 

25 Statement of Invention 

In accordance with a first aspect of the present 
invention, there is provided a method of transmitting a 
data packet from a first communication node to a second 
30 communication node in a mobile network, as claimed in 
Claim 1 . 
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In accordance with a second aspect of the present 
invention, there is provided a communication message, as 
claimed in Claim 13 . 

5 In accordance with a third aspect of the present 

invention, there is provided a communication message, as 
claimed in Claim 14 . 

In accordance with a fourth aspect of the present 
10 invention, there is provided a communication message, as 
claimed in claim 16 . 

In accordance with a fifth aspect of the present 
invention, there is provided a communication node, as 
15 claimed in Claim 17 . 

In accordance with a sixth aspect of the present 
invention, there is provided a communication node, as 
claimed in Claim 18 . 

20 

In accordance with a seventh aspect of the present 
invention, there is provided a storage medium, as claimed 
in Claim 19. 

25 In accordance with an eighth aspect of the present 

invention, there is provided a method for building an 
extended binding cache, as claimed in claim 20. 

In accordance with a ninth aspect of the present 
30 invention, there is provided a method for constructing 
and sending a care-of route advertising message at a 
mobile network node, as claimed in Claim 21. 
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In accordance with a tenth aspect of the present 
invention, there is provided method for constructing and 
sending mobile network prefix advertising message at a 
5 mobile router, as claimed in Claim 22. 

In accordance with an eleventh aspect of the present 
invention, there is provided a storage medium, as claimed 
in Claim 23 . 

10 

In accordance with a twelfth aspect of the present 
invention, there is provided an apparatus, as claimed in 
Claim 24. 

15 In accordance with a thirteenth aspect of the present 
invention, there is provided a communication unit, as 
claimed in Claim 25. 

In accordance with a twelfth aspect of the present 
20 invention, there is provided a communication system, as 
claimed in Claim 26. 

Further aspects of the present invention are as claimed 
in the dependent Claims. 

25 

Brief Description of the Drawings 

FIG. 1 illustrates the movement of a Mobile Network in an 
Internet ; 

30 

FIG. 2 illustrates a known packet data routing mechanism 
for mobile networks when applied to nested mobility; 
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FIG. 3 illustrates a known packet data routing mechanism 
for mobile networks when applied to nested mobility that 
highlights the inefficiency of the data routing; 

5 

FIG. 4 illustrates a known packet data routing mechanism 
for mobile networks when applied to nested mobility that 
highlights the inefficiency of an improved process of the 
data routing; and 

10 

FIG. 5 illustrates a known binding cache for routing data 
packets in mobile node networks. 

Exemplary embodiments of the present invention will now 
15 be described, with reference to the accompanying 
drawings, in which: 

FIG. 6 illustrates a network topology for advertising a 
mobile router mobility within mobile networks, in 
20 accordance with the preferred embodiment of the present 
invention; 

FIG. 7, FIG. 8 and FIG. 9 illustrate flowcharts for an 
MNN router constructing and sending a care-of route 
25 advertisement, in accordance with the preferred 
embodiment of the present invention; 

FIG. 10 illustrates a network topology for sending 
extended BUs to CNs in accordance with the preferred 
30 embodiment of the present invention; 
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FIG. 11 illustrates a flowchart of an MNN generating a 
care -of route, in accordance with embodiments of the 
present invention; 

5 FIG. 12 and FIG. 13 illustrate flowcharts of an MNN 

sending extended BU messages to its CN(s) (and HAs) , in 
accordance with the preferred embodiment of the present 
invention; 

10 FIG. 14 and FIG. 15 illustrate flowcharts of a MNN 

sending an extended BU to its CN(s) (and its HAs) in 
accordance with the preferred embodiment of the present 
invention; 

15 FIG. 16 illustrates a flowchart of a dynamic discovery 
method of a mobile network prefix for a MNN in a mobile 
network, in accordance with the preferred embodiment of 
the present invention; 

20 FIG. 17, FIG. 18, and FIG. 19 illustrate flowcharts of 

processes of MNN routers sending a mobile network prefix 
advertisement message, in accordance with the preferred 
embodiment of the present invention; 

25 FIG. 2 0 illustrates a flowchart of a first node sending a 
data packet to a second node, in accordance with the 
preferred embodiment of the present invention; 

FIG. 21 illustrates preferred examples of data packet 
30 formats sent by a first node to a second node, in 

accordance with embodiments of the present invention; 
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FIG. 22 and FIG. 23 illustrate a mobile network prefix 
solicitation message and a mobile network prefix 
advertisement message respectively, in accordance with 
the preferred embodiment of the present invention; 

5 

FIG. 24 and FIG. 25 illustrate a care-of route 
solicitation message and a care-of route advertisement 
message respectively, in accordance with the preferred 
embodiment of the present invention; 

10 

FIG. 26 and FIG. 27 illustrate an extended BU message 
sent from a LFN and a VMN respectively, in accordance 
with the preferred embodiment of the present invention; 

15 FIG. 28 illustrates an extended binding cache in 

accordance with the preferred embodiment of the present 
invention; 

FIG. 29 illustrates the construction of a care-of -source 
20 route from a received extended BU in accordance with the 
preferred embodiment of the present invention; and 

FIG. 3 0 is a flowchart that illustrates a process of a 
first node receiving an extended BU from a second node in 
25 accordance with embodiments of the present invention. 

Description of Preferred Embodiments 

There is currently no standard mechanism to support 
30 Network mobility adequately, particularly in the case of 
IPv6 for nested mobility data networks. In particular, 
there is no provision or support for route optimisation. 
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This is a major issue, as nested mobility is a very 
realistic scenario for Mobile Router applications. In 
addition route optimisation is much more important with 
regard to movement of a Mobile Network, than for movement 
5 of a single Mobile Node, since the amount of traffic 
handled is much greater. 

The preferred embodiment of the present invention is 
described with respect to route optimisation in 

10 transmitting at least one data packet between a 

corresponding node (communication unit) and a local fixed 
node (or vice versa) . In this context, route 
optimisation may be viewed as w the- shortest-path" direct 
communication between a Mobile Network Node (MNN) and its 

15 Correspondent Nodes (CNs) , particularly for an MNN within 
a Mobile Network where a nested mobility (Mobile Networks 
visiting Mobile Networks) scenario exists. 

It is envisaged that the corresponding node may be any 
20 communication unit capable of sending a data packet 
across a data network (such as the Internet) , for 
example, a web server, a PC, or a workstation running a 
web server such as www . yahoo . com , etc. The CN may also 
be any mobile data communication unit such as a general 
25 packet radio system (GPRS) device or a 3 rd generation (3G) 
cellular phone, a personal digital assistant (PDA), etc., 
connected' to the data network through any type of access. 
Note that the CN may also itself be located in a mobile 
network. 

30 

As explained in the previous section, a Mobile Router 
(MR) must send a Binding Update (BU) message to its Home 
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Agent (HA) when moving to a Foreign Network. By sending 
a BU message to its HA, the MR maintains IP reach-ability 
for itself as well as for nodes it serves (MNNs) . 

5 In accordance with the preferred embodiment, no 

restriction is placed on the mechanism to be used by the 
Mobile Network to inform its Home Agent about its new 
location. In this regard, any known approach such as 
those described in [3] Thierry Ernst, Hong-Yon Lach, IETF 

10 Internet -Draft draf t-ernst-mobileip-v6-network- 02 . txt, 
June 2001, or [5] T. J. Kniveton, IETF Internet -Draft 
draft-kniveton-mobrtr-OO.txt, November 2001, may be 
adapted and used. The adaptation of such techniques 
enables route optimisation to be achieved in cases of 

15 nested Mobility. 

Furthermore, in an enhanced embodiment of the present 
invention, it is shown how the approaches in [3] Thierry 
Ernst, IETF Internet -Draft draf t-ernst-mobileip-v6- 
20 network-02.txt, June 2001, and [5] may be leveraged in 
order to also achieve route optimisation on the path HA 
MN (where MN is either a host or a router) . 

The preferred embodiment of the present invention 
25 utilises three key concepts, which are used either singly 
or preferably in combination. The three key concepts 
are : 

(i) Advertising a Mobile Router's mobility within 
30 its Mobile Network. 
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(ii) Sending of one or more extended Binding 
Update messages by MNNs to their respective CNs. An 
extended Binding Update message sent by a MNN would 
include a "care-of route" instead of a single care-of 
5 address in vanilla Mobile IP. The care-of route is an 

ordered list of IP addresses that a CN will use to source 
route its packets to the MNN on the shortest path, 
thereby achieving route optimisation. 

10 (iii) Receiving of extended BU messages by the 

CNs. In response to the received BU messages, source 
route packets addressed to MNN through the route derived 
from the care-of route address in order to achieve route 
optimisation . 

15 

(A) Mobile Router Advertising its mobility in the Mobile 
Network: 

20 In order to realize route optimisation for MNNs in the 

case of a single Mobile Network, as well as multi-layered 
aggregated Mobile Networks (nested mobility) , the 
inventive concepts described herein propose to make MNNs 
aware of the mobility of the Mobile Networks (or Mobile 

25 Routers) that they are attached to. This is in direct 
contrast to the approach proposed in [3] where a Mobile 
Router's mobility is hidden to its respective MNNs. 

In order to announce it has moved to a new point of 
30 attachment, a Mobile Router (e.g. MR1) will send a "Care- 
of Route Advert! semen t" message into the Mobile Network 
it serves addressed to all the nodes behind it (i.e. any 
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LFNs, LMNs, VMNs) . This message contains the Care-of 
address of the MR1 itself, as well as the care-of 
addresses of all the Mobile Routers above MR1 in the 
hierarchy of aggregated Mobile Networks, in the case of 
5 nested network mobility. This list of above mobile 
routers' care-of addresses is preferably ordered and 
constructed dynamically through all the Care-of Route 
Advertisement sent at each level of the hierarchy of 
aggregated Mobile Networks. 

10 

Referring now to FIG. 6, a network topology 600 for 
advertising such a mobile router's mobility within mobile 
networks, is illustrated, in accordance with the 
preferred embodiment of the present invention. In 

15 particular, the topology shown in FIG. 6, illustrates the 
supporting nested mobility, in accordance with the 
preferred embodiment of the present invention. A skilled 
artisan would recognise that the number of elements shown 
in the network of FIG. 6 are limited for clarity purposes 

20 only . 

The network topology shown in FIG. 6 illustrates a second 
Mobile Network (MR2) visiting a first Mobile Network 
(MR1) that is attached to a visited network. The first 
25 Mobile Network includes a fixed router (LFR1) that serves 
its own link. 

Since MR1 650 is visiting a foreign network 110, it has 
acquired a Care-of Address {MRl_CoA} 652. The foreign 
30 network 110 is fixed, so there is no Care-of Route 

Advertisements forwarded in the link between the visited 
link 110 and MR1 650. In accordance with the preferred 
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embodiment of the present invention, MR1 650 constructs 
its own Care-of Route Advertisement message and includes 
its own Care-of Address 652 in the advertisement message. 

5 This message is multicasted to all nodes within (below) 
its own link (MR1 Link 155) through its ingress 
interface. All nodes on the link will therefore receive 
this advertisement message. When receiving such a 
message, Routers (LFR, LMR, VMR) are expected to extract 

10 the ordered list of Care-of addresses 652 and forward 
this list on to the links that they serve. In this 
regard, the second MR (MR2) 660 forwards the Care-of 
addresses 652 to its own link (MR2 link) 230. If this 
router is a top router of a Mobile Network not within its 

15 home network (i.e. a VMR as in the case of MR2 660), it 
will append its own Care-of address to the list received. 
MR2 660 will then include the MR2 Care-of address 662 in 
the generation of a new ordered-list . MR2 will then 
generate its own Care-of Route Advertisement message to 

20 be multicasted on its own link (MR2 link) 23 0, through 
its ingress interface. As a consequence, MRl__CoR is 
advertised in the first Mobile Network (including MR1 
link 155 and LFR1 link 670) whilst the ordered-list 
{MRl_CoR 652, MR2_CoR 662} is advertised in the second 

25 Mobile Network 230. 

The process of informing CN2 655 of the optimum route to 
LFN2 665 via the MR2 care-of -address 662, using an 
extended BU message, is described later. In this manner, 
30 the full route for the data packet can be determined by 
improved extraction, utilisation and advertisement of 
address data throughout the networks . 
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The process shown in FIG. 6 illustrates a practical 
scenario, where many nested levels may exist. Hence, a 
skilled artisan would appreciate that the aforementioned 
5 process may be easily generalised to an example of nested 
mobility involving n successive levels (n mobile routers 
MR X/ MR n and n corresponding home agents HAi, HA n ) . 

Referring now to FIG. 7 , FIG. 8 and FIG. 9, various 
flowcharts 700 , 800 , 900 are illustrated for any router 
in a mobile network, such as MR VMR LFR and LMR, to 
construct and send a list of care-of addresses to be 
included in a Care-of Route advertisement (CoR_Advt) 
message, in accordance with the preferred embodiment of 
the present invention. Also, these processes are valid 
only for M3STN that are routers (e.g. LFR, MRs) . 

Basically, a router in a Mobile Network will send a 
CoR_Advt message in response to one of three events: 

(i) Reception of a CoR_Advt on its egress interface 
that modifies its own CoR, as described in FIG. 7; 

(ii) Periodic sending of a CoR_Advt, as described in 
FIG. 8; and 

(iii) Reception of a Care-of route solicitation 
(CoR_Sol) message on an ingress ifc, as described in FIG. 
9. 

In FIG. 7, the process starts at step 710. A new 
CoR_Advt message is received on its egress interface, as 
30 shown in step 72 0, and the list of care-of addresses 

extracted, as described further in process A of FIG. 11. 
If the respective MNN's Care-of Route (MNN_CoR) has not 
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been changed in step 740, the process ends in step 780. 
However, if the respective MNN__CoR address has been 
changed in step 740, the router builds a new CoR_Advt 
message and includes (appends) in it the new MNN_CoR, as 
5 shown in step 750. The new CoR__Advt message is then sent 
to all nodes through all ingress interfaces of the 
respective MNN, as in step 760. 

In FIG. 8, a flowchart illustrates the preferred 
10 operation if a periodic CoR__Advt message timer has 

expired in step 82 0. In this case, the router builds a 
new CoR_Advt message and includes (appends) in it to the 
MNN_CoR , as shown in step 850. The new CoR_Advt message 
is then sent to all nodes through all ingress interfaces 
15 of the respective MNN, as in step 860. The CoR_Advt 
message timer is then re-started in step 870. 

A router in a mobile network (MR, LFR, LMR, VMR) will 
start periodic transmission of CoR_Advt messages only 

20 when its CoR becomes non-null (i.e. contains at least one 
address) . It is envisaged that the router will terminate 
this periodic emission when its CoR becomes null/empty. 
For example, a MR will start the periodic emission when 
it (or a top MR) is moving out of its home network and 

25 terminate the periodic transmission when it (or the top 
MR) is returns to its home network. 

In FIG. 9, a flowchart illustrates the preferred process 
upon reception of a Care -of route solicitation (CoR_Sol) 
30 message on an ingress ifc, as shown in step 92 0. In this 
case, the router builds a new CoR_Advt message and 
includes (appends) in it MNN_CoR, as shown in step 950, 
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when the (CoR_Sol) message is received on an ingress 
interface if c_j . Two possible approaches are envisaged 
for the sending of a CoA__Advt operation in step 960. A 
first approach is to send the CoA_Advt message to the 

5 source address of the care-of Route Solicitation message 
(CoR__Sol) through ifc_j . Alternatively, the CoA_Advt 
message may be sent to all nodes on the links through the 
if c_j . Note that when a mobile router (MR) changes its 
location, it should send a CoR_Sol message, in order to 

10 receive a CoR_Advt message in return. The MR is then 
able to compute its new Care-of Route (CoR) . This CoR 
will be made of the ordered list of addresses received in 
the CoR__Advt message (if not empty) to which MR's new 
Care-of address is appended. Since this new CoR is not 

15 empty, the MR will then start periodic sending of its own 
CoR_Advt me s s age s . 

Several approaches are envisaged for the implementation 
of Care-of Route Solicitation and Care-of Route 

20 Advertisement messages. First, the messages may be 

implemented as an Internet Control Message Protocol for 
IPv6 , IETF RFC 1885 (ICMPv6) extension, or as any new 
protocol on top of IP (v4 or v6) , such as User Datagram 
Protocol, IETF RFC 768 (UDP) , Transmission Control 

25 Protocol, IETF RFC 793 (TCP), etc. 

Secondly, a Care-of Route Advertisement message may be 
sent to the IPv6 all-node link-local multicast address. 
In this case, the message will be sent only on the local 
30 link. A preferred manner would be to send the Care-of 
Route Advertisement to the IPv6 all -node site -local 
multicast address, where the site is the whole Mobile 
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Network served by this MR. This would help reduce 
operation on intermediate routers (LFR, LMR at home) in 
the Mobile Network since the Care-of Route Advertisement 
would then be forwarded transparently to all the links of 
5 the Mobile network. In this manner, there is no need for 
this intermediate router (LFR, LMR at home) to extract 
and copy the CoR list. 

A preferred implementation of these messages would be to 
10 define them as extensions of ICMPv6 Router Solicitation 
and ICMPv6 Router Advertisement messages. A Care-of 
Route Advertisement message would be an ICMPvS Router 
Advertisement message (RA) including a new n Care-of Route 
Advertisement" option. A Care-of Route Solicitation 
15 message would be an ICMPv6 Router Solicitation message 
(RS) including a new "Care-of Route Advertisement" 
option. The Care-of Route Advertisement option would be 
included in RA when a router has to announce its (non- 
empty) _ CoR within the mobile network. The Care-of Route 
20 Solicitation option may be included in RS by a MNN to 
explicitly request for a RA with the Care-of Route 
Advertisement option. If this option were not included 
in the RA, this would mean that the CoR of this router is 
null /empty. 

25 

Referring now to FIG. 24 and FIG. 25, a Care-of Route 
Solicitation message and a Care-of Route Advertisement 
message are illustrated respectively, in accordance with 
the preferred embodiment of the present invention. 

30 

The Care-of Route Solicitation (CoR_Sol) message 2400 in 
FIG. 24 is an ICMPv6 Router Solicitation message, 
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extended with the new w Care-of Route Solicitation" 
option. It includes a single IP header 2425 that 
includes an IP source address 2410 for a host and an IP 
destination address 2420 indicating the all-routers IP 
5 multicast address. The IP header 2425 is followed by a 
router solicitation message 2430 containing the Care-of 
Route Solicitation (CoR_Sol) option. 

The Care-of Route Advertisement (CoR_Advt) message 2500 
10 in FIG. 25 is an ICMPv6 Router Advertisement message 
extended with the new "Care-of Route Advertisement" 
option. It includes a single IP header 2525 that 
includes an IP source address 2510 for a router's ingress 
interface and an IP destination address 2520 indicating a 
15 node (or all nodes on the link) that is to receive the 
packet. The IP header 2525 is followed by a router 
advertisement message 253 0 containing the Care-of Route 
Advertisement option that includes the Care-of Route 
(i.e. ordered list of addresses) as advertised by the 
20 router. 



B) MNNs sending extended Binding Updates to their 
respective CNs: 

25 

Any MNN, including a LFN, a LMN or a VMN, in a Mobile 
Network is expected to send so-called extended Binding 
Updates to its CNs in order to achieve route optimisation 
on the path CN MNN. In accordance with the preferred 
30 embodiment of the present invention, an extended BU 
message sent by a MNN would include a u care-of route" 
instead of a single care-of address, as known in Mobile 
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IP. As described above, the care-of route is the 
ordered-list of IP addresses for the CN to derive a 
source route from, in order to route its packet to the 
MNN through the shortest path (i.e. route optimisation). 

5 

Referring now to FIG. 10, a network topology 1000 for 
sending extended BUs to CNs, is illustrated in accordance 
with the preferred embodiment of the present invention. 
For clarity purposes only, the topology follows on from 
10 that described above with respect to FIG. 6. 

Each MNN in the Mobile Network derives its care-of route 
from the Care-of Route Advertisement messages it receives 
from its upper router. For instance, LFN1 675 care-of 
15 route is a single hop route equal to MR1 650' s Care-of 
Address {MRl__CoA} 652. LFN1 675 then transmits an 
extended BU message 1010 indicating its care-of route to 
CN1 1030. 

20 In contrast, LFN2 665' s care-of route is a two-hop route 
equal to {MRl_CoA -> MR2_CoA} . In this context, the LFN2 
665 Care-of Route utilises MR2 CoA 662 and the upper 
router from MR2, namely MR1 650 's CoA 652. LFN2 665 then 
transmits an extended BU message 102 0 indicating the 

25 MRl_CoA 652 and the MR2 CoA 662 to CN2 655. 

Referring now to FIG. 11, a preferred algorithm for a MNN 
to generate its own care-of route (MNN_CoR) , in 
accordance with embodiments of the present invention, is 
30 described. The process (process A) starts at step 1110. 
When the MNN receives a new CoR_Advt message on its 
interface ifc_i, in step 1120, it determines whether it 
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is an egress interface, in step 113 0. If it is not an 
egress interface, the CoR_Advt is ignored and the process 
ends in step 1190. In this case, the MNN Care-of Route 
is unchanged. 

5 

If ifc_I in an egress interface, then the MNN extracts a 
new CoR (new_CoR) - ordered list of IP addresses - from 
the CoR_advt in step 1140, and a determination is made as 
to whether the MNN is at home (i.e. ifc_i is attached to 

10 its home IP subnet) in step 1150. If the MNN is at home, 
the MNN__CoR is replaced by the new Care -of Route 
information in step 1180, if there is a difference 
between the routes in step 1170. If the MNN is not at 
home, the MNN care-of route is constructed by appending 

15 the MNN care-of address (obtained in the visited network) 
to the ordered-list of care-of addresses received in the 
care-of route advertisement message, in step 1160. 

Note that a MNN may not maintain such a Care-of Route if 
20 it does not intend to benefit from route optimisation on 
the path CN-^MNN, or on the path HA->MNN. However, in the 
preferred embodiment of the present invention, it is 
recommended that such Care-of Route knowledge be 
maintained, in order to leverage the approaches described 
25 in [3] and [5] . In this manner, it is possible to 

achieve route optimisation on the path HA -> MN, where the 
MN is either a host or a router, as described later. 

Note that the approach described in FIG. 11 is valid for 
30 any MNN, either a router or a host, either fixed or 
mobile . 
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Referring now to FIG. 12 and FIG. 13, flowcharts of an 
MNN sending extended BU messages to its CN(s) (and Home 
Agent - HA) , are illustrated in accordance with the 
preferred embodiments of the present invention. The 
5 flowcharts are again applicable to any MNN, either a host 
or a router, fixed or mobile. 

FIG. 12 describes a flowchart 1200 for sending extended 
BU messages to its CN(s) (and HA) following a reception 

10 of a CoR_Advt message on its egress interface, in step 
1215. Upon reception of a CoR_Advt message, the MNN 
performs process 'A 1 described in FIG. 11, to generate 
its own CoR, as shown in step 1220. If its CoR has not 
changed in step 1225, the process ends, in step 1265. 

15 However, if the CoR has changed in step 1225, the MNN 

determines all of its CNs that need to receive an updated 
CoR message, in step 1230. In order to send an extended 
BU message containing the updated CoR message, in step 
1240, the MNN steps through each of the CNs, starting 

20 with the first CN in step 1235. If the CN receiving the 
extended BU message containing the updated CoR message 
transmission is not the last CN identified by the MNN, in 
step 1245, the process moves to the next CN in step 1250 
until all CNs have received the transmission. 

25 

A preferred, optional step is for the MNN, which is not 
at home, to send a message including its new Care-of 
Route (CoR) to its Home Agent (HA) , either an Extended BU 
or an Extended Prefix Scope BU (if the MNN used [3] to 
30 send BU to its HA), as shown in steps 1255 and 1260. 
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FIG. 13 describes an alternative flowchart 1300 for 
sending extended BU messages to its CN(s) (or its HA) 
following periodic sending of extended BUs (EBUs) to CNs 
(and again HA if MNN is a mobile host or router) . Again, 

5 this periodic sending takes place only when the MNN 1 s CoR 
is non-null following expiration of the periodic EBU 
timer associated to a particular CN (e.g. CNi) or MNN' s 
HA, in step 1320. The extended BU message containing the 
updated CoR message is sent to CNi (or HA) in step 1330. 

10 The timer function, associated to the respective CN (e.g. 
CNi or HA), is then re-started in step 1340. 

Note that in relation to FIG. 12 and FIG. 13, a CN may be 
a fixed or mobile host in the Internet as well as another 
15 MNN (from the same or different Mobile Network) . 

Still referring to FIG. 12 and FIG. 13, if the MNN (host 
or router) is at home (i.e. is a LFN, a LMN at home), the 
MNN sends an extended Binding Update to all its CNs (and 
20 not to its HA since it is at home) . If the MNN (host or 
router) is in a visited network (i.e. is a VMN) , the MNN 
sends an extended Binding Update to all its CNs as well 
as preferably its Home Agent. 

25 The MNN may send an extended Binding Update to its Home 
Agent, in case it wants to achieve route optimisation on 
the path HA -> MNN. This approach extends the techniques 
proposed in [3] and [5] , by sending extended BUs instead 
of their basic Binding Updates. In the case of [3], the 

30 Mobile Router (MR) sends a so-called prefix scope BU 

message to its HA. In this context, we define here an 
extension of this binding update message called x extended 
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prefix-scope binding update', which includes the MR Care- 
of route instead of only MR care-of address. This 
extended prefix- scope binding update may be sent by the 
MR to its HA to achieve route optimisation on the path HA 
5 -» MR. 

In the case of [5] , the Mobile Router (MR) sends a basic 
Mobile IP binding update. In this context, we define an 
extension of this BU message as an 1 extended Binding 
10 Update' (as detailed above) . This includes the MR Care- 
of Route instead of only MR care-of address. This 
extended binding update may be sent by the MR to its HA 
to achieve route optimisation on the path HA MR. 

15 It is worth mentioning that each MNN that sends extended 
BU messages preferably maintains an * extended Binding 
List', defined as an extension of the Mobile IP binding 
list, where Care-of Addresses are replaced with Care-of 
Routes . 

20 

Referring now to FIG. 14 and FIG. 15 illustrate 
flowcharts of an optimised process for an MNN sending an 
extended BU to its CN(s) (and its HA) for intra-mobile- 
network communication, in accordance with an enhanced 

25 embodiment of the present invention. It is envisaged 

that the enhanced process improves network performance by 
avoiding sending "useless" extended BU messages in the 
case of intra-mobile-network communication. In fact, 
when two nodes (either fixed, or mobile at home) in the 

30 same mobile network (i.e. not separated by a Mobile 

Router away from home) are sending packets to each other, 
route optimisation will be realised naturally by the 
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routing infrastructure within the mobile network. As 
such, there is no need for them to exchange extended BU 
messages between each other. 

5 In FIG. 14, as an extension to the flowchart of FIG. 12, 
when the MNN is a host at home (i.e. is a LFH, or a LMH 
at home) , the MNN sends an extended Binding Update to 
only its CNs that are not in the same mobile network, as 
in step 1410. Also, when the MNN is a router at home 

10 (i.e. is a LFR, or a LMR at home), the MNN sends an 

extended Binding Update to only its CNs that are not in 
the same mobile network, as in step 1410. If the MNN 
(host or router) is in a visited network (i.e. is a VMN) 
in step 1420, the MNN sends an extended Binding Update to 

15 only CNs that are not in this visited mobile network, in 
step 1240. For CNs that are in the visited mobile 
network, the MNN may send an extended Binding Update, or 
preferably send a modified extended Binding Update where 
only one address is specified in the care-of route, i.e. 

20 only the MNN' s own care-of address, in step 1430. 

The mobile MNN (host or router) preferably sends also a 
Binding Update to its Home Agent in step 1260 and 1450. 
Two cases are considered below, in this regard. When the 

25 MNN has moved out of its home mobile network, the MNN 
preferably sends an extended Binding Update to its HA. 
When the MNN is in a foreign IP-subnet within its home 
mobile network, the MNN may send an extended Binding 
Update. Alternatively, the MNN may send a modified 

30 extended Binding Update where only one address is 

specified in the care-of route, i.e. its own Care-of 
Address. 
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Again, it is envisaged that the MNN may send an extended 
BU message to its Home Agent, in the case where the MNN 
wants to achieve route optimisation on the path HA MNN/ 
5 by sending extended BUs in the operation of [3] or 
extended prefix scope BUs in the operation of [5] as 
described above. 

A similar enhancement to FIG. 13 is described in FIG. 15 , 
10 with the transmission of extended BU messages containing 
only the MNN_CoA to respective CNs that are operating in 
the same Mobile Network as the MNN, as shown in steps 
1510, 1520, 1530. 

15 Referring now to FIG. 26 and FIG. 27 an extended BU 
message sent from a LFN and a VMN are illustrated 
respectively, in accordance with the preferred embodiment 
of the present invention. 

20 The extended BU message sent from a LFN message 2600 in 

FIG. 26 includes a single IP header 2625 that includes as 
IP source address 2610 the LFN and as IP destination 
address 2620 for the CN' s address. The IP header 2625 is 
followed by a Mobile IPv6 BU message 263 0 containing the 

25 Care-of Route mobility option incorporating the LFN's 
Care - of Route . 

The extended BU message sent from a VMN message 2700 in 
FIG. 27 includes a single IP header 2725 that includes an 
30 IP source address 2710 of the VMN care-of address and an 
IP destination address 2720 for the CN. The IP header 
2725 is followed by a Mobile IPv6 BU message 273 0 
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containing the Care-of Route mobility option 
incorporating the VMN' s Care-of Route. 

Referring now to FIG. 16 a flowchart 16 00 of a dynamic 
5 discovery method of a mobile network prefix for any MNN 
in a mobile network is illustrated, in accordance with 
the enhanced embodiment of the present invention 
described above. In this context, a node such as a MNN 
is able to know whether a second node, say its CN, is in 
10 the same current Mobile Network as itself when sending an 
EBU to say the CN, as described above. 

The process (process B) starts at step 1610. When the 
MNN receives a new Mobile Network Prefix Advertisement 

15 message (Mobile_Network_Pref ix_Advt) on its interface 
ifc_i, in step 162 0, it determines whether it is an 
egress interface, in step 163 0. If it is not an egress 
interface, the Mobile_Network_Pref ix_Advt is ignored and 
the process ends in step 1670. In this case, the MNN' s 

20 mobile network prefix (MNN_Mobile_Netowrk_Pref ix) is 

unchanged. If ifc_i in an egress interface, then the MNN 
extracts a new Mobile Network Prefix 
(new_Mobile_Network_Pref ix) and its prefix length 
(new_Mobile_Network_Pref ix_Length) from the 

25 Mobile_Network_Pref ix__Advt in step 1640, and a 

determination is made as to whether the MNN' s home 
address in ifc_i matches New_Mobile_Network_Pref ix on the 
first New_Mobile_Network_Pref ix_Length bits, in step 
1650. If it matches, the MNN_Mobile_Network_Pref ix and 

30 MNN_Mobile_Netowrk_Pref ix_Length are replaced by the new 
information in step 1650, and the process ends in step 
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1670. If there is not a match, the process ends directly 
in step 1670. 

Note that the approach described in FIG. 16 is valid for 
5 any MNN, either a router or a host, either fixed or 
mobile . 

Referring now to FIG. 17, FIG. 18 and FIG. 19, various 
flowcharts 1700, 1800, 1900 are illustrated for a fixed 
10 router in a mobile network (i.e. LFR) to construct and 
send its own Mobile Network Prefix Advertisement 
(Mobile_Network_Pref ix__Advt) messages, in accordance with 
the enhanced embodiment of the present invention. 

15 Basically, a fixed router in a Mobile Network will send a 
Mobile_Network_Pref ix_Advt message in response to one of 
three events: 

(i) Reception of a Mobile_Network_Pref ix_Advt on an 
20 egress interface that modifies its own 

MNN_Mobile_Network_Pref ix, as described in FIG. 17; 

(ii) Periodic sending of a 
Mobile_Network_Pref ix_Advt, as described in FIG. 18; and 

25 

(iii) Reception of a Mobile Network Prefix 
Solicitation message (Mobile_Network_Pref ix_Sol) on an 
ingress ifc, as described in FIG. 19. 

30 In FIG. 17, the process starts at step 17 05. A new 
Mobile_Network_Pref ix_Advt message is received on an 
egress interface, as shown in step 1710, and the new 
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Mobile Network Prefix (New__Mobile_Network_Pref ix) and its 
length are extracted, as described further in process B 
of FIG. 16. If the respective MNN_Mobile_Network_Pref ix 
and MNN_Mobile__Network__Pref ix__Length have not been 
5 changed in step 172 0, the process ends in step 173 5. 
However, if the respective MNN_Mobile_Network_Pref ix 
and/or MNN_Mobile_Network_Pref ix__Length have been changed 
in step 1720, the router builds a new 

Mobil e_Network_Pref ix_Advt message and includes (appends) 
10 in it the new MNN_Mob i 1 e_Ne two r k_P r e f i x and 

MNN_Mobile_Network_Pref ix_Length, as shown in step 1725. 
The new Mobile_Network_Pref ix_Advt message is then sent 
to all nodes through all ingress interfaces of the 
respective MNN, as in step 1730. The flowchart described 
15 in FIG. 17 only applies to a fixed router in a mobile 
network . 

In FIG. 18, a flowchart illustrates the preferred 
operation if a periodic Mobile_Network_Pref ix__Advt 
20 message timer has expired in step 1810. In this case, 
the router builds a new Mobile_Network_Pref ix__Advt 
message and includes (appends) in it the 
MNN_Mobile_Network_Pref ix and 

MNN_Mobile_Network_Pref ix_Length, as shown in step 1815. 

25 The new Mobile__Network_Pref ix_Advt message is then sent 
to all nodes through all ingress interfaces of the 
respective MNN (fixed router), as in step 1820. The 
Mobile_Network_Pref ix_Advt message timer is then re- 
started in step 1825. The flowchart of FIG. 18 applies 

30 to any router in a mobile network (MR, LMR, LFR, VMR) . 
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A router in a mobile network (MR, LFR, LMR, VMR) will 
start periodic transmission of Mobile_Network_Pref ix_Advt 
messages only when its CoR becomes non-null (i.e. 
contains at least one address) . It is envisaged that the 
5 router will terminate this periodic emission when its CoR 
becomes null/empty. For example, a MR will start the 
periodic emission when it (or a top MR) is moving out of 
its home network and terminate the periodic transmission 
when it (or the top MR) has returned to its home network. 

10 

In FIG. 19, a flowchart illustrates the preferred process 
upon reception of a Mobile Network Prefix Solicitation 
message (Mobile__Network_Pref ix_Sol) on an ingress ifc # as 
shown in step 1910. In this case, the router builds a 

15 new Mobile_Network_Pref ix__Advt message and includes 
(appends) in it MNN_Mobile_Network_Pref ix and 
MNN_Mobile_Network_Pref ix__Length, as shown in step 1920, 
when the (Mobile_Network_Pref ix_Sol) message is received 
on an ingress interface if c_j . Two possible approaches 

20 are envisaged for the sending of a 

Mobile_Network_Pref ix_Advt operation in step 1925. A 
first approach is to send the message to the source 
address of the Mobile Network Prefix Solicitation message 
(Mobile_Network_Pref ix_Sol) through if c_j . 

25 Alternatively, the Mobile Network Prefix Advertisement 

message may be sent to all nodes on the links through the 
ifc_j . The flowchart of FIG. 19 applies to any router in 
a mobile network (MR, LMR, LFR, VMR) . 

30 Note that when a mobile router (MR) changes its location 
(and thus get a non-null CoR) , it should send a 
Mobil e_Network_Pref ix_Advt on its ingress interfaces. 
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This mobile router may know this prefix from its internal 
configuration. On the other hand, fixed routers in the 
mobile network (i.e. LFR) may not a-priori know the 
mobile network prefix they belong to and can discovery it 
5 dynamically thanks to the process described in FIG. 17. 
Such fixed routers may of course send a 

Mobile_Network_Pref ix_Sol message, in order to receive a 
Mobile^ Network_Pref ix__Advt message in return. 

10 Several approaches are envisaged for the implementation 
of Mobile Network Prefix Solicitation and Mobile Network 
Prefix Advertisement messages. First, the messages may 
be implemented as ICMPv6 extension, or as any new 
protocol on top of IP, UDP, TCP, etc. ICMP, UDP and TCP 

15 are protocols that build upon IP(v4 or v6) : 

ICMPv6: Internet Control Message Protocol for 
IPv6, IETF RFC 1885 
- UDP: User Datagram Protocol, IETF RFC 768 
20 - TCP: Transmission Control Protocol, IETF RFC 793 

Secondly, a Network Prefix Advertisement message may be 
sent to the IPv6 all-node link-local multicast address. 
In this case, the message will be sent only on the local 

25 link. A preferred manner would be to send the Care-of 
Route Advertisement to the IPv6 all-node site-local 
multicast address, where the site is the whole Mobile 
Network served by this MR. This would help reduce 
operation on intermediate routers (i.e. LFR) in the 

30 Mobile Network since this message would then be forwarded 
transparently to all the links of the Mobile network. In 
this manner, there is no need for this intermediate 



CR00568P . spec PCT V final 



10 June 2003 



WO 2004/002106 



PCTVEP2003/006209 



- 42 - 

router (i.e. LFR) to extract and copy the Mobile Network 
Prefix. 

A preferred implementation of these messages would be to 
5 define them as extensions of ICMPv6 Router Solicitation 
and ICMPv6 Router Advertisement messages. A Mobile 
Network Prefix Advertisement message would be an ICMPv6 
Router Advertisement message (RA) including a new "Mobile 
Network Prefix Advertisement" option. A Mobile Network 

10 Prefix Solicitation message would be an ICMPv6 Router 

Solicitation message (RS) including a new "Mobile Network 
Prefix Advertisement" option. The Mobile Network Prefix 
Advertisement option would be included in RA when a 
router has to announce the mobile network prefix within 

15 the mobile network. The Mobile Network Prefix 

Solicitation option may be included in RS by a MNN to 
explicitly request for a RA with the Mobile Network 
Prefix Advertisement option. 

20 Referring now to FIG. 22 and FIG. 23, a mobile network 
prefix solicitation message and a mobile network prefix 
advertisement message are illustrated respectively, in 
accordance with the preferred embodiment of the present 
invention. 

25 

The mobile network prefix solicitation message 2200 in 
FIG. 22 is an ICMPv6 Router Solicitation extended with 
the new Mobile Network Prefix Solicitation option. It 
includes a single IP header 2225 that includes an IP 
30 source address 2210 for a host and an IP destination 
address 2220 indicating the all-routers IP multicast 
address. The IP header 2225 is followed by the router 
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solicitation message 223 0 containing the mobile network 
prefix solicitation option proposed in this document. 

The mobile network prefix advertisement message 23 00 in 
5 FIG, 23 is an ICMPv6 Router Advertisement message 

extended with the new mobile network prefix advertisement 
option. It includes a single IP header 2325 that 
includes an IP source address 2310 for a router's ingress 
interface and an IP destination address 232 0 indicating a 

10 node (or all nodes on the link) that is to receive the 
packet. The IP header 2325 is followed by the router 
advertisement message 233 0 containing the mobile network 
prefix advertisement option that includes the mobile 
network prefix and the mobile network prefix length 

15 advertised by the router. 

C) Correspondent Nodes and Home Agent receiving extended 
Binding Update: 

20 

Referring now to FIG. 20, a flowchart 2000 illustrates a 
process for a first node to send a data packet to a 
second node based on the parsing of its Extended Binding 
Cache (EBC) , in accordance with the preferred embodiments 

25 of the present invention. A first node, for example a CN 
or HA, receives an indication that a data packet is to be 
sent to a second node, for example a MNN, as shown in 
step 2020. The CN searches for the MNN's address within 
an extended binding cache (EBC) that stores the Care-of 

30 Source routes derived from care-of route information 
received in extended BUs, as in step 2030. 
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If the MNN's address is found, in step 2040, the CN (or 
HA) is able to source route the packet, through the Care- 
of Source route found in the EBC, to the MNN's address 
achieving route optimisation, as in step 2050. 
5 Otherwise, the CN sends the data packet to the MNN 

directly to MNN' s Home Address using the known technique, 
as shown in step 2060. 

Referring now to FIG. 21, preferred examples of data 
10 packet formats, sent by a first node, say a CN, to a 
second node, say a MNN, are illustrated in accordance 
with the preferred embodiments of the present invention. 

A first format of a data packet 2100 includes a single IP 
15 header 2110 that includes an IP source address 2112 and 
an IP destination address 2114 equal to the first IP 
address in CN' s Care-of Source Route to MNN. The single 
IP header 2110 is followed by a routing header 2120 
containing the (m-1) other addresses (from CN' s Care-of 
20 Source route to MNN) in the route to the second node. 
The data payload 2130 follows the routing header. 

A second format of a data packet 2150 includes x m' 
consecutive IP headers each including respective IP 

25 source addresses 2112 , 2152, 2162, 2172 and respective IP 
destination addresses 2114, 2154, 2164, 2174. The x m' 
consecutive IP headers do not therefore need a separate 
routing header, so the data payload 218 0 follows the IP 
headers. Each of the consecutive IP headers has its IP 

30 destination address set equal to one of the IP addresses 
of CN's Care-of Source route to MNN. The fist header 
contains the first address of the Care-of Source Route 
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(CoSR) , the second header contains the second address, 
and so on to the last header. The final IP header 2172, 
2174, together with the data payload 218 0, constitutes 
the original packet 2190 to be sent from the first node 
5 to the second node . 

Each node (CN, MNN, HA) that is expected to receive 
extended Binding Updates is to maintain an extended 
Binding Cache (EBC) . The EBC is herein defined as an 

10 extension of Mobile IP binding cache where care- of 
addresses are replaced with "care-of source routes" 
(CoSR) derived from the care-of routes (CoR) received in 
the extended Binding Updates. It is worth mentioning 
that the care-of source route listed in the extended 

15 binding cache may be slightly different (i.e. shorter) 
from the care-of route received in the extended Binding 
Update . 

Referring now to FIG. 2 8 an extended binding cache 28 00 
20 is illustrated in accordance with the preferred 
embodiment of the present invention. 

The extended binding cache 28 00 includes a list of 
entries 2810, 2840, 2870, each one specific to a home 

25 address of a MNN. The extended binding cache entry 2810 
includes, for example, a first home address 2 815, with a 
link 2818 to a first Care-of Source route 282 0, if one 
has been determined. The first Care-of Source route 2820 
includes respective linked Care-of Source route addresses 

30 2825, 2830, and 2835 to identify the route to the first 
home address. The first entry 2810 is linked 2837 to a 
second entry 2840 having a link 2848 from a second home 
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address 2845 to a second Care-of Source route 2850 , if 
one has been determined. The second Care-of Source route 
2850 includes respective linked Care-of Source route 
addresses 2855, 2860 # and 2865 to identify the route to 
5 the second home address. A similar arrangement and link 
2867 is performed to a third entry 2870 , and so on. 

It is within the contemplation of the invention that the 
extended BU may also include entries for a mobile router 

10 (MR) prefix and prefix length. This is particularly 
useful when an MR sends an extended prefix- scope BU to 
its HA or CNs, as an extension to [3] , where the CoR 
replaces the CoA in the prefix-scope binding update. In 
this case, the Home Address field is replaced with a 

15 "prefix and prefix length" field in the EBC of the 
respective HA or CNs. 

Referring now to FIG. 29, the construction of a care- of - 
source route 2900 from a received extended BU is 

20 illustrated, in accordance with the preferred embodiment 
of the present invention. A first node Care-of Route 
(Nl_CoR) contains an ordered list of Care-of Route 
addresses (Nl_CoR [1] , Nl_CoR[2] , ...) 2910. When the first 
node Nl receives an extended BU message from a second 

25 node N2 containing N2 ' s Care-of Route (N2_CoR) , the first 
node compares the two ordered list of Care-of Route 
addresses, to determine when there is a difference 
between them 2940. The address from N2_CoR that was 
determined as being different, and all subsequent 

30 addresses from N2_ CoR, is then used to generate a new 

Care-of Source Route 293 0 for data packet transmissions 
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from Nl to N2 . This process is further described with 
respect to the flowchart of FIG. 30. 

Referring now to FIG. 30, a flowchart 3 000 a process of 
5 determining a Care- of Source Route to be included in an 
extended Binding Cache is illustrated, in accordance with 
preferred embodiments of the present invention. A first 
node (Nl) receives an extended Binding Update from a 
second node (N2) and needs to determine the care-of 
10 source route to be included in the extended Binding Cache 
for this entry (N2) . 

The process starts at step 3002. When a first node (Nl, 
which may be itself a MNN at home or in a foreign 
15 network, or any host in the topology) receives an EBU 

containing a new Care-of Route for a second node (N2) , in 
step 3 0 04, Nl determines whether this N2 Care-of Route 
(received in the EBU) is empty in step 3006. 

20 If the new Care-of Route for N2 received in the EBU is 
empty, in step 3006, Nl searches through its extended 
Binding Cache to check whether there is an entry (i.e. a 
care-of source route) for this second node in the EBC, as 
shown in step 3008. If no entry exists in the EBC, the 

25 process ends in step 3046. In this case, no entry in 
Nl's extended binding cache is needed for N2 . When 
' addressing packet to N2 7 s home address, the data packet 
from Nl will be directly on the shortest path (route 
optimisation is achieved without needing source routing) . 

30 However, if an entry exists in the EBC in step 3008, the 
second node entry is removed (i.e. Nl_CoSR(to N2) ) in 
step 3010, before the process ends at step 3046. 
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If the new N2 Care-of Route received in the EBU is not 
empty, in step 3006, a determination is made in step 3012 
as to whether a Care-of Route entry is available for the 

5 first node. If a Care-of Route is not available for the 
first node in step 3 012, a first node (Nl) Care-of Source 
Route to the second node (N2) is generated to be equal to 
the second node Care-of Route (Nl_CoSR(to N2) : = N2_CoR) , 
as shown in step 3 014. Nl then searches through its 

10 extended Binding Cache to check whether there is an entry 
(i.e. a care-of source route) for this second node in the 
EBC # as shown in step 3016. If no entry exists in the 
EBC, an entry for N2 is added to the EBC (Nl_CoSR(to 
N2)), in step 3020 and the process ends in step 3046. If 

15 an entry exists in the EBC in step 3016, the second node 
entry is updated (i.e. Nl_CoSR(to N2)) in step 3018, 
before the process ends at step 3046. 

If the first node has its own Care-of Route in step 3 012, 
20 all addresses in the two nodes care-of routes (Nl and N2) 
are searched, starting with setting a counter (i=0) in 
step 3022. Nl compares, one by one, the IP addresses in 
its own care-of route (Nl_CoR) with the IP addresses 
listed in the care-of route of the extended Binding 
25 Update received from node N2, in step 3 024. 

It starts with the first addresses Nl_CoR(l) and 
N2_CoR(l), and continues thereafter. If a match for a 
particular address of the first and second nodes care-of 
30 routes is found, in step 3026, a determination is made as 
to whether the second node Care-of Route address is the 
last address, in step 3028. If it is the last address, 
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the complete Care-of Route of N2 has been searched, in 
step 3 030, and the process moves to step 3008 as 
described above. If the second node Care-of Route 
address is not the last address, in step 3 028, a 
5 determination is made as to whether the first node Care- 
of Route address is the last address for the first node, 
in step 3032. If the first node Care-of Route address is 
not the last address, in step 3 032, the counter is 
incremented in step 3 034, and the next addresses searched 
10 in step 3024. If the first node Care-of Route address is 
the last address, in step 3 028, or no match was found in 
step 3 026, the searching process stops in step 3036 and 
the care-of source route to N2 , from Nl, is set in 3038. 

15 In 3 038, the care-of source route to N2 , from Nl, is set 
to be equal to ordered list of addresses part of N2's 

care-of route starting from the i th address to the last 
fch. 

one. This i address being the one where the loop in 

N2's care-of route addresses stopped in step 3036. That 
20 is: Nl_CoSR(to N2) = {N2_CoR(i) -> N2_CoR(i+l) ... 

N2_CoR(n-l) -> N2_CoR(n)}. Nl then searches through its 
extended Binding Cache to check whether there is an entry 
(i.e. a care-of source route) for this second node in the 
EBC, as shown in step 3 040. 

25 

If no entry exists in the EBC, an entry for N2 is added 
to the EBC (Nl_CoSR(to N2) ) , in step 3042 and the process 
ends in step 3046. If an entry exists in the EBC in step 
3 040, the second node entry is updated (i.e. Nl_CoSR(to 
30 N2) ) in NX's EBC in step 3044, before the process ends at 
step 3046. 
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If Nl has no care-of route (NR_CoR is empty or does not 
exist) in step 3 012, then the care-of source route to N2, 
from Nl, is set to be equal to N2 ' s care-of route in step 

5 3014. That is: Nl_CoSR(to N2) = N2_CoR. Nl then 

searches through its extended Binding Cache to check 
whether there is an entry (i.e. a care-of source route) 
for this second node in the EBC, as shown in step 3016. 
If no entry exists in the EBC, an entry for N2 is added 

10 to the EBC (Nl_CoSR(to N2) ) , in step 3020 and the process 
ends in step 3046. If an entry exists in the EBC in step 
3 016, the second node entry is updated (i.e. Nl_CoSR(to 
N2)) in Nl's EBC in step 3018, before the process ends at 
step 3046. 

15 

Nl should then source route the packet via the care-of 
source route to N2 in order to achieve route 
optimisation, as described with reference to FIG. 21 and 
FIG. 22. This can be implemented in several ways, as 

20 described previously. A first way is to use the IPv6 

Routing Header. In this case, the first address in the 
care-of source route is set as the destination address in 
the IPv6 header and the remaining addresses of the care- 
of source route (CoSR) are set in the Routing Header in 

25 the same order. A second way is for the first node to 

build y n' level of encapsulation of the data packet to be 
sent, where x n' is the number of addresses in the care-of 
source route. The encapsulation #k will have the address 
#k, of the ordered-list of addresses in the care-of 

30 source route, as the destination address. 
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Furthermore, the various steps described above need not 
necessarily be performed in the order they have been 
described. A skilled artisan would recognise that an 
alternative order may be used, where benefit can still be 
5 gained in the route optimisation process. 

It is to be appreciated that the arrangement and specific 
details of interfaces, address types, routers etc. in the 
above embodiments are merely examples, and the invention 

10 is not limited to these examples. The invention should 
be viewed as capable of being applied to other aspects of 
the Internet or other. types of data networks or protocols 
and subnets thereof. Furthermore, the invention may also 
be applied to networks other than the Internet, when such 

15 networks have subnets and access networks corresponding 
to those described above for the case of the Internet. 

The invention, or at least embodiments thereof, tend to 
provide the following advantages, singly or in 
20 combination: 

(i) A data packet may be transmitted much more 
efficiently, using this improved route optimisation 
technique . 

25 

(ii) Improved privacy of data packet 
transmissions, as each node in the topology is 
responsible in sending their own Binding Updates to their 
CNs and Home Agent. Hence, each node is able to decide 

30 whether it wishes to disclose its current location by 
sending a Binding Update in order to perform route 
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optimisation. This is a clear advantage over [3] where 
privacy is not allowed. 

(iii) The security solutions defined by the IETF, 
5 to provide "address ownership" authorisation (e.g. Return 

Route -ability) , are still applicable in the context of 
the present invention. This is again a clear advantage 
over [3] , which requires a new security mechanism to be 
introduced. 

10 

(iv) A secured exchange of new messages (e.g. 
u Care-of Route Advertisement") introduced in the present 
invention can be very easily realised, either through 
shared secret (in the case of nodes belonging to the same 

15 organisation) or through a new IETF protocol such as PANA 
in the case of a Mobile Node (host or router) visiting a 
foreign network. 

(v) A solution for efficient data routing in IPv6, 
20 IPv4 or similar data network protocol has been achieved, 

particularly for systems supporting nested network 
mobility. 

Whilst the specific and preferred implementations of the 
25 embodiments of the present invention are described above, 
it is clear that one skilled in the art could readily 
apply variations and modifications of such inventive 
concepts . 

30 Thus, a mechanism, apparatus and associated methods to 
support route optimisation in Network mobility, 
especially in the case of IPv6, have been described, 
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whereby the disadvantages associated with known 
mechanisms/ apparatus and associated methods have been 
substantially alleviated. In particular, a mechanism, 
apparatus and associated methods to support route 
5 optimisation in the case of nested mobility, have been 
described. 
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